In a communication network comprising a plurality of transceivers it may be necessary to keep the transceivers synchronized so that they use the same timing for communications. One transceiver may act as a master that defines the timing for the communication system. The other transceivers act as slaves and keep synchronized with the timing of the master. One such network is a Bluetooth (trademark) piconet as described in the Specification of the Bluetooth System v1.1, Part B (Baseband).
One way of maintaining synchronization within the network is for the master to transmit periodically radio packets. In the Bluetooth system the master transmits radio packet messages with an Access Code in the preamble of a packet header. This Access Code is detected by a slave receiver. The reception of a message sent from the master allows the slave to compare its timing with that of the master and to adjust its timing to maintain synchronization. This may be done by adding an offset value to the value of the native clock in the slave.
The Bluetooth Specification, revision 1.1 requires “The slave shall be able to receive the packets and adjust RX timing as long as the timing mismatch remains within the +/−10 μs uncertainty window”.
Consequently, in current implementations the slaves listen for a message in a listening window of fixed duration (20 μs) centred at the time a message is expected to be received. This means that if a master is transmitting more than 10 μs earlier or more than 10 μs later than the slave is expecting, the slave will not be able to receive the packet and will not be able to adjust its timing. Since both master and slave are using different native clocks that are allowed to drift around ±20 ppm, the slave may lose connection when it has not received a packet from the master within a time tconloss where:
      t    conloss    =                    10        *                  10                      -            6                          ⁢        s                              (                      20            +            20                    )                *                  10                      -            6                                =          250      ⁢                          ⁢      ms      
Therefore if the master has not polled the slave for more than 250 ms or the environment is disturbed for that time, in the worst case, the connection will be lost.
During a normal, undisturbed active connection between master and slave, this time is never reached since the master has to poll the slave within TPoll, that is 25 ms by default. However, if the master performs an Inquiry or Page, this continuous polling is interrupted for the time it takes to complete the Inquiry or Page, which is typically 5-10 s. As a consequence, it is very likely that all slaves that are connected to a piconet, will lose connection as soon as the master performs an Inquiry or Page.
One solution to this problem would be to increase the size of the fixed uncertainty window. This is unattractive because it is not required by the Bluetooth Specification and because it would result in a significant and permanent increase in power consumption by the receiver.
Another solution to the problem is provided in the Bluetooth Specification. It allows the master to force its slaves into a Hold mode for the page/inquiry time to prevent loss of synchronization. However, it is not mandatory for transceivers to support the Hold mode. In addition, the master has to separately force each slave to the Hold mode, which wastes air capacity.
The same problem of loss of synchronization can occur if the normal connection between the master and slave is disturbed. This may result from interference or multipath propagation causing degradation of the message such that it is not received in the listening window of the receiver. The use of Hold mode is not a solution to this problem.
It would be desirable to improve synchronization within a communications network.